This invention relates generally to software thread management and, more particularly, to a thread connection enhancement to a connector application program interface that provides alternate thread support in the form of thread consistency to connectors.
In computer science terminology, a thread, sometimes shorthand for thread of control, generally represents an execution stream through a software process. Threads can only exist if a process exists. When the process starts, it does all of the required initialization, such as address spacing and the like, which requires use of system resources. Threads allow multiple processes to share the same address space, resources, and so on, while running concurrently. A thread often owns a small or minimal set of resources, including a machine state, a control stack, machine interface (MI) automatic storage, and anchors for thread local storage. Threads share other process resources, such as static and heap storage, program activations, etc., with other threads. A threaded application that makes use of, for example, static storage must synchronize access to that storage among its threads. Neither the programming language, such as C, nor the operating system provides implicit synchronization.
When an application uses more than one thread at a time, it is generally referred to as multi-threading. If an application is saturated, starting a new thread will often help. Starting a new thread is fast and economical, and it thus improves performance versus starting a new process to do the same job. Unlike processes, one advantage of multi-threading is that there are no resource sharing concerns. While applications vary, multi-threading can provide many benefits, such as improved application scalability due to reduced use of resources, superior response time in creating new threads as compared with new processes, and centralized management of client connections in a single server.
However, some back-end systems, that is, external systems like databases or messaging servers, which provide information access via a published interface, are more restrictive and confine operations to that of a single particular thread per connection, or execution instance which uses the published interface to access the back-end system—usually the thread to which the back end has granted a connection handle. This leads to incompatibility problems when a multi-threaded client application seeks to interface with this type of restrictive back end system. The restrictive back-end systems may require completely single threaded server applications that maintain thread consistency. In such systems, multiple threads could still exist in a thread consistent environment, provided that each connection is associated with only one thread. In contrast, a multi-threaded server application requires that the connectors support multi-threading, since the connector APIs of these multi-threaded server applications assume that connections may be used freely between threads, and that each connector supports thread execution without regard to thread consistency.
Thus, this type of restrictive back-end system simply will not support multiple threads from a multi-threaded server application. This is unfortunate since many server applications are multi-threaded, and it is desirable to be able to implement these applications without regard to the back-end system. Accordingly, there is a need for a system that allows a multi-threaded server application to interface with a restrictive back-end system that requires thread consistency. The present invention fulfills this and other needs.